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Commissioner for Patents 
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Alexandria, VA 22313-1450 

Sir/Madam: 

I, Brigide Mattar, of the Town of Mount Royal in the Province of Quebec, Canada, being 
duly sworn, in supplement to the statements set forth in the Affidavit under 37 CFR 1.131 
executed by me on April 1 8 2007, depose and state: 

1 . Attached hereto and marked Exhibit "J" is a copy of a letter dated March 28, 2001 that I 
prepared and transmitted to Mrs. Jennifer Marvin of Canadian National Railway 
Company (hereinafter referred to as "CN"). As indicated in the body of the letter, its 
purpose was to transmit to Mrs. Jennifer Marvin a first draft of the above-identified 
patent application. 

2. Attached hereto and marked Exhibit "K" is a copy of an e-mail dated March 28, 2001 that 
I prepared and transmitted to Mrs. Jennifer Marvin of CN. As indicated in the body of 
the e-mail, its purpose was to transmit to Mrs. Jennifer Marvin a first draft of the above- 
identified patent application. 

3. Attached hereto and marked Exhibit "L" is a copy of the first draft of the above-identified 
patent application including a specification and a set of drawings sent as enclosures to the 
letter identified as Exhibit "J" and as attachments to the e-mail identified as Exhibit "K". 
This document describes the present invention as claimed in the above-identified patent 
application. 1 confirm that I prepared the first draft of the above -identified patent 
application based on information provided to me by CN. 

4. I swear this Affidavit with the knowledge that willful false statements and the like are 
punishable by fine and imprisonment, or both under section 1001 of Title 18 of the 
United States Code and that such willful false statements may jeopardize the validity of 
the above-referenced application or any patent issued thereon. 
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Brigide Mattar 
bmattar@smart-biggar.ca 

Montreal file no. 10103-169 



March 28, 2001 
Mrs. Jennifer Marvin 

CANADIAN NATIONAL BY COURIER 

277 Front Street West 
5 th Floor 

Toronto, Ontario 
M5V 2X9 

Subject: Proposed Patent Application in Canada 

Applicant: CANADIAN NATIONAL RAILWAY CORP. 
Inventor(s): 

Title: METHOD AND SYSTEM FOR 

PROCESSING INVOICES 

Your Ref.: 



Dear Jennifer: 

According to your instructions, we have now completed the preparation of a very rough 
draft of a patent application that you will find enclosed for your review. 

The patent application contains two sections, namely the specification and the claims. 
The purpose of the specification is to provide a written description of the inventive 
concept and also a specific example on how to embody this inventive concept. In many 
countries of the world, including the United States and Canada, the Law requires that the 
specific example disclosed is the best mode known to the inventor to put the invention 
into practice. Failure to comply with this requirement may result in an eventual patent 
being held invalid or unenforceable. Accordingly, in reviewing the patent application 
draft, we request that you ensure that the description of the invention that is provided is 
complete, technically accurate and that the example of how to carry-out the invention in 
practice is the one that the inventor considers the most desirable. 
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Another important point to keep in mind while reviewing the application is to ensure that 
all the information on which eventually you may desire to seek patent protection is 
disclosed. More specifically, it is always desirable to present in the application several 
embodiments of how to carry-out the invention. If you have developed or if you know 
how alternate embodiments can be manufactured or used, please provide us with this 
additional information so that we can enter it in the application. 

The section of the patent application that contains the claims is extremely important and 
we strongly advise that you consider it carefully. The purpose of the claims is to define 
the scope of the subject matter on which you are presently seeking protection. Thus, if 
the claims are drafted too narrowly, the eventual patent may not provide you with a level 
of protection that is satisfactory. It is therefore, important that you consider each claim of 
the application and if you find that the claims contain elements that are not critical to the 
inventive principle and that may unduly limit the scope of protection, please let us know 
so that we can review them. 

Another important issue that must be considered before filing the application is the 
question of inventorship. Only the individuals that have effected a considerable 
contribution to the development of the subject matter on which protection is sought 
(subject matter as defined in the claims) qualify as inventors in the patent application. In 
reviewing the claims we therefore request that you identify the individuals that have 
developed the claimed subject matter so that we can note our records that they should be 
named as inventors. In this regard, note that even though the contribution of an 
individual may be restricted to a single claim, this suffices for this individual to qualify as 
inventor. 

In order to qualify as inventor, the contribution of an individual should be significant, not 
merely as a result of participation in a project. The inventor is the one that has originated 
either alone or in conjunction with others, the subject matter in a claim. Generally, the 
mere completion of laboratory work under guidance of another does not suffice to raise 
the contribution to an inventorship level. The same is also true for managerial activities 
in a project. 

Please note that during the prosecution of the application, the inventorship may change as 
a result of cancellation of claims or amendments made to claims. It is therefore important 
that you review in detail any modifications to the claims as they may occur in the future 
and advise us if the subject matter on which one or more inventors bases its (their) 
inventorship status is withdrawn so that we can effect the modifications to the 
inventorship accordingly. 

When identifying the inventors for this application please also provide us with their 
residential addresses and their citizenship. This information will be useful to us during 
the preparation of the formal papers necessary to file the application. 
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Finally, we need to know if this application will be assigned to a third party of if it will be 
filed under the names of the inventors. If the application is assigned, then we need to 
know the name of the assignee and its official address so that we can prepare the 
necessary title document that will be sent to you for execution by the inventors. 

Please provide us with your comments, preferably in writing, as soon as possible. 

Yours truly, 

FETHERSTONHAUGH 




SPG/BM/ma Brigide Mattar 

for: Stephan P. Georgiev 

Ends. 

cc: Ms. Brigide Catellier (with enclosures) 
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3/28/01 

Mattar, Brigide 



To: Jennifer Marvin (E-mail) 

Subject: Patent Application 

OUR REFERENCE: 10103-169 
Jennifer, 

I am sending herewith for your review a first draft of the patent application for the Method and System 
for Processing Invoices providing a multi-stage invoice payment process. Keep in mind that this is a 
very rough draft. I am also sending you a paper copy of the application by courier along with a letter 
explaining in detail the different sections of the patent applications and as well as describing required 
additional information. 

Please provide me with your comments at your earliest convenience preferably by April 5. 2001 . 
Please do not hesitate to contact me if you have any questions or comments during your review. 

Regards, 




Specifiatlon.doc Vtslo-10103-169 (2).pdf 



Brigide Mattar 
Smart & Biggar 
Fetherstonhaugh & Cie/Co. 

1000 ruede la Gauchetiere Ouest/St.West, Suite 3400 
Montreal, Quebec 
Canada H3B 4W5 
Tel: (514) 954-1500 
Fax: (514) 954-1396 

Adresse electronique/E-mail: bmattar@smart-biggar.ca 

*™RENSEIGNEMENT IMPORTANT****** 
u PRESENTE COMMUNICATION EST CONFIDENTIELLE ET EST STRICTEMENT DESTINEE A 
LA PERSONNE IDENTIFIEE CI-HAUT. SI VOUS N'ETES PAS CE DESTINATAIRE, VEUILLEZ 
NOTER QUE TOUTE DIVULGATION OU UTILISATION DE CETTE COMMUNICATION EST 
ILLEGALE. SI VOUS AVEZ REQU LA PRESENTE COMMUNICATION PAR ERREUR, VEUILLEZ 
IMMEDIATEMENT NOUS EN AVISER PAR TELEPHONE AU (514) 954-1500 (A FRAIS VIRES) ET 
NOUS RETOURNER L'ORIGINAL, SANS EN CONSERVER DE COPIE. 

******IMPORTANT INFORMATION****** 
THE INFORMATION CONTAINED IN THIS TRANSMISSION IS CONFIDENTIAL AND ONLY FOR 
THE INTENDED RECIPIENT IDENTIFIED ABOVE. IF YOU ARE NOT THE INTENDED 



3/28/01 

RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY DISSEMINATION OR USE OF THIS 
COMMUNICATION IS UNLAWFUL. IF YOU HAVE RECEIVED THIS TRANSMISSION IN ERROR, 
PLEASE IMMEDIATELY NOTIFY US BY TELEPHONE (514) 954-1500 (COLLECT) OR BY 
RETURN E-MAIL AND DESTROY THE ORIGINAL MESSAGE, RETAINING NO COPY. 
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PRIVILEGED AND CONFIDENTIAL 

1 

Title: Method and System for Processing Invoices 
Field of the Invention 

5 This invention relates to a system and method for 

facilitating online commerce over a public network such as 
the Internet or an interactive T.V. cable network. More 
particularly, this invention relates to a system and method 
for conducting online processing of an invoice including 
10 multi-stage invoice handling capabilities. 

Background of the Invention 

Online commerce has experienced dramatic growth in 
recent years and this growth is expected to continue into 
the coming decades. Internet service providers are, more and 
more, connecting users to the Internet at no cost, thus 
eliminating barriers to an Internet connection. At the same 
time, merchants are increasingly developing sites on the 
World Wide Web (or simply "WWW" or "Web") that customers can 
access to order goods and/or services. It is now fairly 
common for a customer to browse a .merchant's catalogue, 
select a product or service and place an order for the 
product/service all electronically over the' Internet. 
Similarly, it is becoming increasingly common for merchants 
to allow payment of invoices electronically. Typically, the 
invoice is sent electronically to the customer via 
electronic mail or made available to the customer over a 
network by providing the customer . with network access 
capability. 



15 



20 
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30 
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U.S. Patent 6,128, 603 issued to Dent et al . on October 
3, 2000) describes a consumer-based system for analyzing, 
managing and paying electronic bill statements received from 
a biller. The biller electronically transmits a customized 
5 statement to a consumer's computer terminal over the 
Internet. The biller' s electronic bill is presented to the 
consumer through a user interface. After reviewing the 
electronic bill the consumer can enter how much of the bill 
to pay, from which account to pay from, and the desired 
10 payment date. The entered information is then transmitted 
to the biller for processing. The contents of U.S. Patent 
6,128,603 are incorporated herein by reference. 

Similarly, U.S. Patent 6,070,150, issued to Remington 
15 et al. on May 30, 2000, describes an electronic payment 
system in which a biller electronically transmits a bill to 
a consumer over the Internet. The bill may arrive at the 
.consumer's terminal via email or a notification for the 
consumer to check a billing mailbox. The consumer receives 
20 the bill that can be displayed in the form of a user 
interface. After reviewing the bill the consumer is able to 
enter the amount to be paid, the date of payment and from 
which account the money can be taken. The system described 
in Remington et al. also includes the ability to let the 
25 consumer dispute an item in an invoice. The contents of U.S. 
Patent 6,070,150 are incorporated herein by reference. 

A deficiency with the above-described systems for the 
payment electronic of invoices is that they are ill suited 
30 to certain business-to-business environments. Notably, the 
above-described systems do not facilitate the involvement of 
several individuals in the payment of an invoice. In a 
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typical business setting, it is not uncommon for several 
people to be involved at different stages in the payment of 
an invoice such as, for example, a division manager, a clerk 
in the accounts payable department and the manager of the 
5 accounts payable department. In these situations, the 
invoice is typically printed at the division manager's 
office, approved by the division manager and forwarded by 
internal mail (or e-mail) to the accounts payable department 
where one or more individuals authorize the payment to be 
10 made. This process is time consuming and often results in 
delays in the payment of an invoice. 

Consequently there exists a need in the industry to 

provide an improved system and method for processing 

15 invoices that alleviates at least in part the deficiencies 
of prior art systems and methods. 

Suiamary 

20 In accordance with a broad aspect, the invention 

provides a method for electronically presenting and granting 
payment of invoices. The method includes generating an 
invoice at a biller and making the invoice electronically 
available to a customer entity. A first user associated to 
' 25 the customer entity is enabled to approve the invoice and a 
second user associated to the customer entity is enabled to 
authorize payment of the invoice, the second user being 
distinct from the first user. A data element indicating that 
payment of the invoice has been approved is transmitted from 

30 the first user to the biller. Another data element 
indicating that payment of the invoice has been authorized 
is transmitted from the second user to the biller. Payment 
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of the invoice - is processed at the biller when payment of 
the invoice has been approved and authorized. 

An advantage of the present invention is that it allows 
5 a customer entity to obtain account information without 
interacting with a person at the biller f s location. 

Another advantage of the present invention is that it 
allows for at least two individuals to be consulted at 

10 different stages of the payment of an invoice such as at the 
approval stage and at the authorization stage. It will be 
readily appreciated that more than two stages may be present 
and more than two individuals may be involved in the payment 
of an invoice without detracting from the spirit of the 

15 invention. 

In a specific implementation, the data element 
indicating that payment of the invoice has been approved and 
the data element indicating that payment of the invoice has 
20 been authorized are transmitted to the biller independently 
from one another. 

Advantageously, this provides the biller with 
information regarding the stage of the payment of the 
25 invoice. This is particularly advantageous and allows the 
accounts payable at a biller site to readily determine at 
which stage an unpaid invoice is being delayed and to 
determine which person of the customer location to contact. 

30 The users associated with the customer entity may be 

resident in a same location, such as a single office or 
multiple offices in a same building, as well as may reside 
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in geographically remote locations. For example, the first 
user may reside in New York, NY, USA while the second user 
may reside in Vancouver, B.C., Canada. The first user has 
payment approval privileges and the second user has payment 
5 authorization privileges. 

In a specific example of implementation, the invoice is 
electronically transmitted over a network. In a first non- 
limiting example of . implementation, the invoice is 

10 transmitted via e-mail to the first and second users at the 
customer entity. In this implementation, the invoice is 
provided as a data structure including an approval field and 
an authorization field, the approval and authorization 
fields being modifiable by the first and second users 

15 respectively. In a non-limiting example, a field is provided 
allowing the second user to provide payment remittance 
information credit card information, an authorization to 
debit a bank account or an indication that a check will be 
mailed . 

20 

In a second specific example of implementation, the 
invoice is electronically transmitted over the Internet. In 
a non-limiting example of implementation, in order to view 
invoices and other account information, the users associated 

25 with the customer entity log on to a secure web-site using 
login names and associated passwords . The account 
information is displayed on a graphical user Interface on 
the customer's computer terminal. Each unpaid invoice is 
displayed with an approval field and an authorization field. 

30 The approval and authorization fields are modifiable by the 
first and second users respectively where the first user has 
payment approval privileges and the second user has payment 
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authorization privileges. In a non-limiting example, a field 
is provided allowing the second user to provide payment 
remittance information including credit card information, an 
authorization to debit a bank account or an indication that 
5 a check will be mailed. 

Another advantage of the invention is that [JENNIFER : 
IS THERE ANYTHING TO ADD?] 

10 In accordance with another broad aspect, the invention 

provides a computer readable medium including a program 
element executable by a computing apparatus for implementing 
the above described method. 

15 In accordance with a broad aspect, the invention 

provides a system implementing the above-described method. 

In accordance with another aspect, the invention 
provides a method for granting payment of an invoice over a 

20 network, the invoice having been issued by a biller entity 
to a customer entity. The method includes transmitting over 
the network to the biller entity an approval status data 
element associated to the invoice from a first user 
associated to the customer entity. The method also includes 

25 transmitting over the network to the biller entity an 
authorization status data element associated to the invoice 
from a second user associated to the customer entity. 
Payment of the invoice is granted by the customer entity if 
the approval status data element indicates that the invoice 

30 has been approved and the authorization status data element 
indicates that the invoice has been authorized. 
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In a specific implementation, the first user has 
payment approval privileges, the payment approval privileges 
being assigned by the customer entity. The second user is 
distinct from the first user and has payment authorization 
5 privileges, the payment authorization privileges being 
assigned by the customer entity. 

In accordance with another aspect, the invention 
provides a method for processing an invoice over a network, 

10 the invoice having been issued by a biller entity to a 
customer entity. An approval status data element associated 
to the invoice is received over the network at a biller 
entity. An authorization status data element associated to 
the invoice is received over the network at a biller entity. 

15 The biller detects the granting of payment of the invoice if 
the approval status data element indicates that the invoice 
has been approved and the authorization status data element 
indicates that the invoice has been authorized. 

20 In a non-limiting example, payment of the invoice is 

processed at the biller entity when the granting of payment 
of the invoice has been detected. 

In a specific implementation, the approval data element 
25 is associated to a first user. The approval status data 
element and an identifier associated with the first user are 
processed to determine if the first user has payment 
approval privileges. The detection of the granting of 
payment is prevented if the first user does not have payment 
30 approval privileges. Similarly, the authorization status 
data element is associated to a second user. The 
authorization status data element and an identifier 
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associated with the second user are processed to • determine 
if the second user .has payment authorization privileges. 
The detection of the granting of payment is prevented if the 
second user does not have payment authorization privileges. 

5 

In accordance with a broad aspect, the invention 
provides a computer readable medium including a program 
element executable by a computing apparatus for implementing 
the above described method. 

10 

In accordance with a broad aspect, the invention 
provides a method for electronically presenting and granting 
payment of invoices. An invoice is generated at a biller 
and making the invoice electronically available to a 

15 customer entity. A plurality of users associated to the 
customer entity are enabled to complete respective stages of 
a multi-stage invoice handling process and transmit data 
elements indicative that the respective invoices processing 
stages have been completed. Payment of the invoice is 

20 processed at the biller when the data elements indicative 
that respective invoice processing stages have been 
completed are received at the biller. 

Other aspects and features of the present invention 
25 will become apparent to those ordinarily skilled in the art 
upon review of the following description of specific 
embodiments of the invention in conjunction with the 
accompanying figures . 

30 Brief Description of the Drawings 
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Fig. 1 is a block diagram of an electronic invoice 
presentment and payment remittance system in accordance with 
an embodiment of the invention, including a biller computing 
system 116, a network 106, and a customer computing system 
5 102 having a plurality of computing units; 

Fig. 2a is a block diagram depicting one of the 
customer computing units shown in figure 1 in accordance 
with an embodiment of the invention; 

10 

Fig. 2b is a block diagram depicting one of the biller 
computing system 116 shown in figure 1 in accordance with an 
embodiment of the invention; 

15 Figure 3 is a flow diagram of a registration phase for 

use in connection with a process for electronically 
presenting and granting payment of invoices in accordance 
with an example of implementation of the invention; 

20 Fig. 4 is a flow diagram of the process for 

electronically presenting and granting payment of invoices 
in accordance with a specific example of implementation of 
the invention; 

25 Fig. 5 is a non-limiting example of implementation of a 

graphical user interface for presenting a plurality of 
unpaid invoices associated to a customer entity; 

Fig. 6 is a non-limiting example of implementation of a 
30 graphical user interface for presenting an invoice 
associated to a customer entity. 
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Detailed Description 

The method and system for processing invoices have 
multi-stage invoice handling capabilities. The multi-stage 
5 invoice handling process allows different individuals to be 
given different responsibilities in the payment of an 
invoice. In the example described, the multi-stage invoice 
handling process includes two stages, namely an approval 
stage wherein an invoice is approved for payment by a person 
10 permitted to do so, followed by an authorization stage 
wherein the actual payment is made under the authority of a 
second person permitted to do so. It will be appreciated 
that a multi-stage invoice handling process having in excess 
of two stages remains within the scope of the invention. 

15 

Fig. 1 shows an electronic invoice presentment and 
payment remittance system 100 in accordance with a specific 
implementation.. The system 100 allows a customer entity 102 
to view the state of its accounts payable with regards to a 

20 specific biller 104 and to issue payment instructions to 
that specific biller 104. The system 100 also allows the 
specific biller 104 to receive information regarding the 
payment stage of a certain invoice. The system 100 includes 
a biller computing system 116 and a customer computing 

25 system 150 interconnected through a network 106. The biller 
computing system 116 and the customer computing system 150 
include tools for facilitating online commerce transactions 
between the customer entity 102 and the biller entity 104. 

30 The network 106 is a data communication network 

interconnecting the customer computing system 150 and the 
biller computing system 116. In a specific example of 
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implementation, the network is a public network. In the 
illustrated implementation, the data communication network 
106 is embodied in the Internet. It is to be noted that the 
data communication network 106 may be implemented as a 
5 network other that the Internet such as an interactive 
television (ITV) network, a private network such as an 
Intranet or any other suitable network. 

The customer computing system 150 comprises a plurality 

10 of computing units 112 114, each associated to a respective 
user 108, 110. The computing units 112 114 are generally in 
the form of personal computers, although other types of 
computing units may be used including laptops, notebooks, 
hand-held computers, set top boxes, and the likes. The 

15 plurality of computing units 112 114 may be connected to one 
another over an Intranet or may be stand-alone computing 
units. Each of the computing units 112 114 is provided with 
a connection to the network 106. The connection may be. a 
permanent connection through a server at the customer's 

20 premises, or alternatively, a given computing unit may 
occasionally connect to the network 106 through the use of a 
dial-up connection using suitable devices such as a modem 
for example. For the purpose of simplicity, the example 
described herein below considers a customer computing system 

25 150 including two customer computing units 112 114 each 
being respectively associated to a first user 108 and a 
second user 110. It will be readily appreciated that a 
customer computing system 150 including in excess of two 
customer-computing units remains within the invention. 

30 

Figure 2a depicts a block diagram of customer computing 
unit 112. The structure and functionality of customer 
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computing unit 114 is identical to that of customer 
computing unit 112 and as such will not be described. As 
shown, the customer computing unit 112 comprises a processor 
210, a memory 220 and a network I/O 224 (input/output) for 
accessing the network 106. The network I/O 224 can be 
implemented, for example, as a dial-up modem or as a 
permanent network connection. The processor 210 is adapted 
to execute program elements stored in the memory 220 for 
performing certain functions. More specifically, the 

customer computing unit 112 runs an operating system 218 
that supports multiple applications. The operating system 
218 is preferably a multitasking operating system that 
allows simultaneous execution of multiple applications in a 
graphical windowing environment. The memory 220 also 
includes a browser program element 222. The browser program 
element 222 loads into volatile memory 212 when launched and 
executes on the processor 210 atop the operating system 218. 

The customer computer unit 112 may also include e-mail 
software components (not shown) as well as additional 
components and modules. These have been omitted from the 
description for the purpose of clarity. 

The biller computing system 116 includes one or more 
computer servers and one or more computing apparatuses. The 
system includes program elements allowing the biller entity 
104 to manage customer invoices and to provide electronic 
processing of invoices. The biller computing system 116 may 
also include modules for connection to a payment network 152 
(shown in Figure 1). The payment network 152 represents 
existing networks that presently accommodate transactions 
for credit cards, debit cards, checks and other types of 
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financial payment processes. A description of the payment 
network .152 and of the interaction of the biller computing 
system 116 with the payment network is not necessary for the 
understanding of the present invention and as- such will not 
• 5 be described. 

Figure 2b shows a block diagram depicting a schematic 
diagram of the biller computing system 116. As depicted, 
the biller computing system 116 ' comprises a processor 208, a 

10 memory 200 and a network I/O 226 ( input /output ) for 
connection ' to the network 106. The network I/O 226 is 
preferably implemented as a permanent ' network connection 
although dial up connections may be suitable in certain 
embodiments. For example, if the biller computing system 

15 116 interacts with the customer computing system 150 via e- 
mail, then a dial-up connection may be suitable. 

The processor 208 is adapted to execute program 
elements 204 stored in the memory 200 for performing various 

20 functions. The memory 200 also has a data portion 206 
including a customer database 202 and an invoice database 
203/. It will be readily appreciated that the biller 
computing system 116 may include additional components and 
modules. These have been omitted from the description for 

25 the purpose of- clarity. 

The customer database-. 202 includes information 
pertaining to the customers of the biller entity. In a non- 
limiting implementation, for each' customer entity, an entry 
30 is provided including various information data elements 
associated to the customer entity. Amongst others, each 
entry includes a plurality of records, each record including 
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a user identifier with a corresponding ■ password. In 
. addition-, each user identity is associated to respective 
privileges defining stages which the user is permitted to 
complete. In' a specific example, the customer database 
5 includes a first user having payment approval privileges and 
a second. user having payment authorization privileges. ■ The 
table below is a representation of an entry in the customer 
database for customer ABC INC. As shown, ACB INC. has five 
records for users {Userl, User2, User3, User4, User5) . 
■10 . Userl and User4 have payment approval privileges and User2 
has payment authorization privileges. User3 has neither 
payment approval nor payment authorization privileges. 
UserS has both payment approval and payment authorization 
privileges. 

15 



Customer ABC Inc. : User list 


User name 


Password 


Privileges 


Userl 


1234 


Approval: Yes 
Authorization: No 


User2 


9876 


Approval: No 
Authorization: Yes 


User3 


7656 


Approval: No 
Authorization: No 


User4 


5656 


Approval: Yes 
Authorization: No ■ 


User 5 


4321 ■ 


Approval : Yes 
Authorization : Yes 



As a variant, the system provides a plurality of levels 
of ■ permission . For example, regarding approval privileges, 
a first user at the customer site is permitted to approve 
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invoices of up to a first amount limit; a second person 
permitted to approve invoices of up a second amount limit, 
• the second amount limit being higher that ' the first amount 
limit; a third person permitted to approve invoices of up a 
5 third amount limit, the third amount limit being greater 
that .the second amount limit; and so on. Similarly, a. 
plurality of levels of permissions may be provided for the 
other stages of the payment process. The number of levels 
of permissions may vary from one customer to the other 

10 " without detracting on the spirit of the invention and will 
generally be determined on the basis of the organizational 
style of the customer entity.. Advantageously, the use of a 
plurality of levels of permissions allows the invoice 
presentment and payment remittance .system to be better 

■15 suited to large business environments. More specifically, 
it is common in large business environments to delegate to 
senior administrator the responsibility of approving 
invoices for. small expenses' such as paper supplies, for 
example. Larger expenses however generally require the 

20 authorization of a director or vice president in a business. 
This feature permits the two system to' be integrated such as 
automatically differentiate between the two levels.' 

. It is to be expressly understood that other formats for 
25 a customer database are possible without detracting from the 
spirit of the' invention. 

The user identifiers' and the privileges associated to 
each are provided by the customer entity via electronic. 
30 means or .via a registration process. 
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The invoice database 203 includes for each customer in 
the customer database 202 a list of • invoice entries 
associated to invoices "that are not fully paid. Each 
invoice entry includes an invoice identifier,, an " invoice 
5 amount, an unpaid amount and. to a plurality of status data 
elements defining the processing stage of the invoice. 
Other data elements may also be present without detracting 
from the spirit of the invention. . In a non-limiting example. 
of implementation, a given invoice -is associated to an 

1.0 approval status data element, and an authorization status 
data element. The authorization status data element is 
indicative of ■ either one of payment authorization and 
absence of payment authorization by the customer entity. 
The approval status data element is indicative of either one 

15 of payment approval and absence of payment approval by the 
customer entity. 

. The memory also includes a program element 204 for 
operating on the data 206 for managing a customer's account 
20 as well as tools to allow the biller 104 to manage customer 
■ invoices in the invoice database 203 and to provide 
electronic processing of invoice. 

A typical interaction will better illustrate the 
25. functioning of the electronic -invoice presentment and 
payment remittance system 100 and of the program elements 
204. 

Prior to the use of the , elect ronic invoice presentment 
30 and payment remittance system* 100, the customer entity 102 
registers with the biller entity 104. The registration 
between the customer entity and. the biller entity may be- 
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effected over the network 106 or by* providing a form to be 
transmitted by- mail,." fax or other "suitable transmission 
methods. Registration over the network 106 through a web- 
based interface will ' be described herein below. ' with 
5 reference to Figure 3 of the drawings. Registration through 
the other methods will be readily apparent to the reader 
skilled in the art. At step 300, a user at the customer site 
accesses a designated registration website associated with 
the biller through a network link by providing a network 

10 address. This action submits a request for registration of a 
new customer with the biller entity 104. In response, the 
customer entity system downloads a registration module 
implemented by program element' 204 from the biller computing 
system 116 to a customer computing -unit. The registration 

15 module automatically launches to aid the user at the 
. customer site in the completion of the online application 
for registration. In a specific example of implementation, 
the registration module is configured to provide step-by- 
step instructions. At step 302, the user at the customer 

20 site fills out a form including various fields related to 
personal and financial matters, such as company name, 
address, telephone .number, credit card numbers,' bank 
affiliations, and the likes. The user also provides data 
related to preferred payment methods, a list of authorized 

25 user identifiers' and passwords as well as the privileges 
associated to each user identifiers. Some of these 
information ' fields ■ may be omitted and others added without 
detracting from the spirit of , the invention. At this stage, 
the user can enable a first user associated to a user 

.30 identifier to approve invoices and a second. user associated 
. to a user identifier to authorize invoices. In order to 
increase security, the user requesting registration at the. 
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customer site provides an indication that he (she) is 
permitted to register the customer with the biller. This 
may. be effected by providing a pre-arranged password at the 
time of registration, by providing a signed document 
5 attesting to this, or by some other means. Once the 
application for registration is', completed at step 303, the 
application for .registration is submitted to the biller 
entity 104. The registration module facilitates this 
communication between the customer entity 102 and the biller 

10 entity 104. The application form itself, or the registration 
module, contains the necessary routing information to. direct 
the application over the network 106 to the biller- computing 
system 116. At step 308, the biller entity 104 reviews the 
application for registration to determine whether the 

15 customer entity 102 should be permitted to register and 
whether any information is missing. If registration ' is 
denied, for example information is missing, the customer 
entity is already registered or the user requesting 
registration does not haye the permission to do so, at step 

20 312 the biller entity 104 returns a message to the customer 
entity 102 indicating that the application for registration 
■ has been denied. Conversely, if the application is granted, 
the biller entity 104 may return a message indicating that 
the application for registration is successful. 

25. 

Assuming' that the application for registration .is 
granted, at step, 310 the biller computing system 116 .at the 
biller entity 104 creates a " customer account entry in the 
customer database 202 including a customer identifier and a 
30 plurality of records. Each record associated -to the 
customer identifier . includes an authorized user name, 
password and associated privileges. In a specific 
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implementation, the customer entity : entry in the customer 
database includes - at least one record where a first user is 
associated' with payment approval privileges and a second 
record where, a second user is associated with payment 
5 'authorization privileges. A link between the customer 
.account entry in the customer database 202 is associated to 
an entry in the invoice database 203. In a specific 
implementation, the program element further provides 
functionality for allowing a user at the consumer entity to 
10 modify the entries in the consumer database such as to 
add/remove authorized user identifiers, modify passwords, 
modify privileges and so on. Following this, the registered 
customer may conduct payment and processing of invoices over 
the network. 106. 

15 

- With reference to figure 4, at step 400, the biller 
computing system 116 generates an invoice at the biller 
entity. The invoice is stored in the invoice database 203 
and is association with a customer account entry in the 

20 customer database 202. The status- data elements defining the 
processing stage of the invoice are also set at this stage. 
In a non-limiting example, the authorization status data 
element is indicative of an absence of payment authorization 
■ and the approval status data element is indicative of an 

25 absence of payment approval. 

At step 402, the invoice is made electronically 
available to the customer entity. In a first non-limiting 
example of implementation, the- invoice is transmitted via e- 
30 mail to the first and second users at the customer entity. 
In this implementation, the invoice is provided as a data 
structure including an approval field and an authorization 
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field, the approval and authorization fields being 
"modifiable by the first and. second users respectively. In a 
non-limiting .example, a field is, provided allowing the 
second user to provide payment remittance information credit 
.5 card information, an authorization to debit a bank account 
or an indication that a check will be mailed. 

In a second non-limiting example of implementation, the 
invoice is made electronically available over network 106 by 
10 providing a designated website. In . a non-limiting example, 
the website is a secure website implementing an' electronic 
invoice payment system. Authorized users associated with- the 
customer entity can access the site in order to perform 
designated tasks. 

15 

In a second specific example of implementation, the 
invoice is electronically transmitted over the Internet. In 
a non-limiting example of implementation, in- order to view 
invoices and other account information/ the users associated 

20 with the customer entity log on to a secure web-site using 
login names and associated passwords. The account 
information is displayed on a graphical user interface on 
the customer's computer terminal. Each unpaid ' invoice is 
displayed with an approval field and an authorization field. 

•25 The approval and authorization fields are modifiable by the 
first and second users respectively where the first user has 
payment approval privileges and the second user has payment 
authorization privileges. In a non-limiting example, a field 
is provided allowing the second user to provide payment 

30 remittance information including credit card information, an 

authorization to debit a bank account or an indication that 

> 

a check will be mailed. 
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In a typical interaction, users associated to the 
customer entity access- a designated website through, a 
network', link by providing a network address in order to view 
invoices and other account' information. The users log on to 
the secure website by providing login information including 
a customer identifier, a login -name and a password. The 
biller computing system ■ received the login information and 
processes it with respect to the customer database 202. 
More specifically, the processor 208 accesses the customer, 
database 202 to locate the entry corresponding to the 
customer identifier. If no corresponding entry is found, an 
error message is returned to the customer entity. If a 
corresponding entry is found, the processor 208 attempts to 
locate a record corresponding to the login name provided. If 
no corresponding record is found, an error message is 
returned to the user. If a corresponding record is found, 
the password in the record is compared to the password 
provided in the login information. If a match is not found, 
an error message is returned to the user. If a match is 
found, the user is successfully identified. 

Once a user is successfully identified, the account 
information in the invoice database 203 corresponding to the 
customer identifier is transmitted to the user's terminal 
for display on a graphical user interface at .the user's 
computer terminal. The graphical user interface provides 
the user with the. ability to view one or more outstanding 
invoices associated with the biller entity 104. Figure 5 of 
the drawings depicts' a graphical user interface showing 3 
unpaid invoices in a table 504. Each invoice is depicted as 
a row 506 in the table 504, each invoice being associated to 
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various information data elements describing characteristics 
of the invoice. In a . non-limiting example, the graphical 
user interface provides a link for accessing an electronic 
copy of the complete invoice. . In the graphical user 
5 interface shown in Figure 5, this is effected by providing- a 
link associated to the- invoice number, in the invoice number 
column 508. Figure 6 of the drawings depicts a specific 
example of an invoice as resulting from the activation of a 
link in the invoice number column 508. In a' non-limiting 
10 implementation, each invoice is provided with a selection 
column 500 allowing the user to approve or to authorize 
payment of an invoice by checking a box. 

Continuing the typical interaction, at step 404, a 
15 first user accesses the designated website in the manner 
■described above, where the. first user has payment approval 
privileges in the customer database but does not . have 
payment authorization • privileges . Once the first user has 
viewed a certain invoice- there is the choice of approving 
20 the, invoice for payment or authorizing the payment to take 
place or to. do none of the above. 

In a first embodiment, the first user enters in the 
selection column 500 instructions to approve or to authorize 

25 payment of an invoice by checking a box or - filling in a 
field. At step 408, the instructions are .sent to the biller 
entity over the network 106. - The biller entity processes 
the instructions received from the first user. More 
specifically, the biller system determines whether the first 

30 user- was associated to the appropriate permissions in the 
customer database 202 'to* be permitted to issue the 
instructions. Fbr example, if the- first user checks the box 
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associated to payment authorization, the biller system will 
check in the customer database- if the first user has payment 
authorization privileges. Since the first" user has payment 
approval privileges but does not have payment authorization 
privileges, .the biller system will return an error message 
to the first user indicating that the. instructions . are being 
disregarded. If the first user checks the box associated to 
payment approval, the biller system will check in the 
customer database if the first user has payment approval 
privileges. Since the first user, has payment approval 
privileges, the biller system will mark the invoice in the 
invoice database as being approved. 

In a second embodiment, the graphical user interface is 
conditioned on the basis of the privileges associated to the 
user. For example, if the user accessing the system has 
payment ' approval privileges . ' than only the field (s) 
associated to the approval of the invoice is- (are) active 
with the other fields being deactivated or alternatively 
being completely absent. The first user enters in the 

selection column 500 instructions to approve an invoice by 
checking a box. At step. 408, the instructions are sent to 
the biller entity over the network 106. The biller entity 
processes the instructions received from- the first user. In 
this embodiment, the biller entity 'processes the 
instructions received' from the first user to modify the 
status data element associated to the invoice' in the invoice 
database accordingly. However, since only the boxes 

associated .to permitted actions are active, the biller 
system, upon receipt of an instruction, does not need to 
check if the first user was permitted : to issue payment 
approval if this invoice. . 
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Continuing the typical interaction, at step 406, a 
second user accesses the designated website in the manner 
described above, where* the second user has payment 
5 authorization privileges in the 'customer ■ database but does 
not have payment approval privileges. It is to be noted 
that in this specific example of implementation, the second 
user can access the designated website prior to, 
simultaneously with or subsequent to the first user. For 
10 each invoice, ' the second user is presented with the fields 
for- approving the invoice for payment, authorizing the 
payment to take place or to do none of the above. 

In the first embodiment, the second user enters in the 
15 selection column 500 instructions to approve or to authorize 
payment of an invoice by checking .a box. At step 410, the 
instructions are then sent to the biller entity over the 
network 106. The biller entity processes the instructions 
received from the second user. More specifically, the 
20 biller system determines whether the second user was 
associated to the appropriate permissions in the customer 
database 202 to issue the instructions in a similar fashion 
as that described in connection with the first user. If the 
. second user - checks the box associated to payment 
25 authorization, the biller system will modify the status data 
element associated to the invoice in the invoice database 
accordingly 

In a second embodiment, the graphical user interface is 
30 conditioned on the basis of the privileges associated to the 
user. The second user enters "in the selection column 500 
instructions to authorize an invoice by checking a box. At 
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step 410, the instructions are sent to the biller entity 
over the network .106. The biller entity processes the. 
instructions received, from the second user. In this' 
embodiment, - the biller .entity processes the instructions 
received from the second user to modify the status data 
element associated to the invoice in the invoice database 
accordingly. However, since only the boxes associated to 
permitted actions are active, the biller system, upon 
receipt of an instruction, does not need to check if the 
second user was permitted to issue payment authorization of- 
the invoice. 

In a non-limiting example of implementation, subsequent 
to the second user issuing a . payment authorization 
instruction, a payment module automatically launches to aid 
the second user in the completion of the online payment 
authorization stage 414. In a specific. example of 
implementation, the payment module is configured to provide 
step-by-step instructions. The second user fills out a form 
including various fields related to payment instructions. 
The authorization stage may include providing the biller 
with a credit card number, with an authorization to debit a 
bank account or simply an indication that the check will be 
mailed on a certain day. The information regarding the 
payment instructions is submitted t.o the biller entity over 
the network' 106. . The biller entity receives the payment 
instructions. Alternatively, default payment instructions 
may be provided by , the customer at the time of registration 
or subsequently indicate a default manner of paying 
invoices. In this . alternative, step 414 may be omitted. 
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At step 412, the biller computing unit verifies if an 
invoice in the invoice database has been both : approved and 
■authorized. .In the affirmative, the biller computing system 
116 processes- payment of the invoice in a conventional 
manner on the basis of the payment instructions provided by- 
the customer. 

In accordance with another aspect, the system provides 
a mechanism for facilitating dispute resolution regarding 
payment of invoices. More' specifically, in addition to 
approving and authorizing payment of the invoices, the 
graphical user interface is provided with a field allowing 
the user to chose to dispute a certain invoice. When the 
user selects the field, the .graphical user interface causes 
a dispute resolution interface to appear allowing the user 
to: 

1. Enter a modified amount that the user feels is more 
reasonable; 

2. Select from a list of predetermined dispute reasons, 
the reason why the invoice is being disputed. .The list 
includes a variety of possibilities and the user would 
simply have to click a box located next to a given 
reason. The user is also provided with a comment box 
where specific comments regarding the invoice can ■ be 
entered. 

The dispute resolution form is then submitted to the 

biller entity's accounts' receivable department and can be 

dealt with according to the biller' s established procedure. 

■ » 

The submission may be done electronically over the web page, 
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via e-mail or. by conventional snail mail without detracting 
from the spirit of the invention. The dispute resolution 
mechanism allows the biller entity to maintain a historical 
database of customer disputes and allows the biller to 
5 establish a payment /dispute pattern for customers. 

The dispute resolution mechanism allows establishing a 
dialogue between the. biller entity and the, customer -entity, 
thereby allowing the biller to provide the result of an 
10 investigation on a disputed invoice directly to the customer 
without telephone interaction.' 

Although the detailed description describes extensively 
a system for electronically presenting and granting payment 

15. of- invoices where the invoices are accessible via a web 
• based interface, other embodiments are possible. For 
example, invoices may be sent to first and second users at 
the customer entity via electronic mail, the first user 
having payment approval privileges and the second user 

20' having payment authorization privileges. At the customer 
site, the first . and second users open the received 
.electronic mail and the account information contained 
therein is displayed on a graphical user interface on the 
users' computer terminals. The processing of the invoice 

25 .at the. biller site may be effected in a similar fashion as 
that described above. In the case of the transmission of an 
invoice by e-mail, having a graphical . user interface- 
conditioned on the basis of the privileges associated to the 
users to whom the e-mail is sent will result in fewer e-mail 

30 transmissions between the customer entity and the biller. 
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Although the present invention "has been described ' in 
considerable detail with reference to certain • preferred 
embodiments thereof, variations and refinements are possible 
without departing from the spirit of the invention. 
.Therefore, only the appended claims and their equivalents 
should limit the scope of the invention. 
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Claims : 

1) A method for electronically presenting and . granting 
payment of invoices, comprising the following steps;. 

a.) generating an invoice at a biller; 

b) making the invoice electronically available to a 
customer entity; 

c) 'enabling a first user associated ■ to the customer entity 

to approve the invoice; 

d) enabling a second user associated to the customer 
entity to authorize payment, of the invoice, the second 
user being distinct from the first user; 

e) transmitting from the first user to the biller a data 
element indicating that payment of the invoice has been 
approved; 

f) transmitting ' from the second user to the biller a data 
element indicative that payment of the invoice has been 
authorized; 

g) processing payment of the invoice at the biller when 
payment of th.e invoice . has been, approved and 
authorized. 

2) A method as recited in claim 1, further comprising * the 
step of electronically transmitting the invoice over a 
network . 

3) A method as recited in claim 2, further comprising the 
step of electronically transmitting the invoice over the 
Internet-. 
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4) A method as defined in claim 1, wherein the first user has 
payment approval privileges and the second .user has 
payment authorization privileges. 

5 5) A method as defined in claim 4, wherein the first user and 
the second user reside in geographically remote locations. 

6) A method as defined in claim 1, said method further 
comprising: 

10 a) processing an identifier associated with the first user 

to determine if the first user has payment approval 
privileges; 

b) preventing the processing of payment of the invoice if 
the first • user does .not have payment approval 
1.5 privileges. 

7) A method as defined in claim 6, said method further 
comprising : 

a) processing an identifier associated with the second 
20 user to determine if the second user has payment 

authorization privileges; 

b) preventing the processing of payment of the invoice. if 
the second user does not have payment authorization 
privileges. 

25 

8) A method as defined in claim 1, said method further 
comprising enabling the second user to provide payment 
remittance information including data selected from the 
set consisting of a credit card number, an authorization 

30 to debit a bank account and' an indication that a check 

will be mailed. * < 
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9) A computer-readable medium having computer-executable 
instructions for performing steps comprising: 
a) storing. an invoice at a biller entity; 

.b) making the invoice electronically available to a 
customer entity; 

c) enabling a first user associated to the customer entity 
to approve the invoice; 

d) enabling a second user associated to the customer 
entity to authorize payment of the invoice, the second 
user being distinct from the first user; ' 

e) transmitting from the first user to the biller entity a 
data element indicative that payment of the invoice has 
been approved; 

. f) transmitting from the second user to the biller entity 
a data element indicative that payment of the invoice 
has been authorized;, 
g) processing payment of the invoice at the biller entity 
when payment of the invoice has been approved and 
authorized. 

10) A computer-readable medium as described in claim 9, 
having further computer-executable instructions ' for 

• enabling the second user to specify payment instructions 
including an amount to be paid on the invoice. 

11) A computer-readable medium as- 'recited in claim 10, 
having further. computer-executable instructions for 
performing an additional step of presenting the invoice to 
the customer entity through a graphical user' interface. 
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12) A method for granting payment of an invoice over a 
network-, the invoice 'having been issued by a biller entity 
to a customer entity, said method comprising: 

a) transmitting a first data ' element' indicating that 
payment of the invoice has been approved' by a first 
user associated to the customer entity to the biller; 

b) transmitting a second data element indicating that, 
payment of the invoice' has been authorized by a second 
user associated to the customer entity to the biller 
entity; 

payment of the invoice being granted by the customer 
entity when the first data element and the second data 
element have been transmitted to the biller, indicating 
that the invoice has been approved and authorized. 

13.) A method as defined in claim 12, wherein said method 
further, comprises: 

a) processing an identifier associated with the first user 
tp determine if the first user has payment approval 

. privileges; 

b) precluding granting of the invoice if the first user' 
does not have payment approval privileges. 

14) A method as defined in claim 13, wherein said method 
further comprises: 

a) processing an identifier .associated with the second 
user to determine if the second user has ■ payment 
authorization privileges; 

b) precluding granting of the invoice if the second user 
does not have payment authorization privileges. 
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15) A method as defined in claim 14, wherein ' the second 
. user is distinct from the first user. 

16) A method as defined in claim 15, wherein the network is 
a global computer network. 

17) A method as defined in claim 16, wherein the first user*, 
and the second user reside in geographically remote 
locations and are associated to a first computer terminal 
and a second computer terminal respectively, each of said 
first computer terminal and said second computer terminal 
having a respective link established between itself and . a 
computing apparatus associated to the biller entity. 

18) A method - as defined in claim 12, said method further 
comprises transmitting from the second user a data element 
selected from the set consisting of a credit card number, 
an authorization to debit a bank account and an indication 
that a check will be mailed. 

19) A method for processing an invoice over a network, the 
invoice having been issued by a biller entity to a 
customer entity, said method comprising: 

a) receiving over the network at a biller entity a first 
instruction data element for modifying an approval 
status data element associated to the invoice; 

b) receiving over the network at a biller entity a second 
instruction data element for modifying an authorization 
status data element associated to the invoice, ; 

c) detecting granting of payment of the invoice at the., 
biller entity when:. 
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i) the approval status data element is indicative of 
payment approval; and. 

ii) the authorization status data element is 
indicative of payment authorization. ■ 

5 • 

20) A method as defined in claim 19, wherein said 
authorization status data element .is indicative of either 
one of payment authorization or absence of payment 
authorization by the customer entity. 

10 

21) A method as defined in claim 20, wherein said approval 
status data element is indicative of either one of payment 

• approval or absence of payment approval by the customer 
entity. 

15 

22) . A method as ' defined in claim 19, said method further 
comprising processing payment of the invoice at the' biller 
entity when the granting of payment of the invoice has 
been detected. 

20 

23) A method as defined in claim 19, wherein the first 
instruction data element is associated to a first user, 
said method further comprising: - 

a) processing an identifier associated with the first 
25 . user to determine if the • first user has payment 

approval privileges; 
' b) i preventing the detection of the granting of payment, if 
the first user does not have payment approval 
privileges. 



30 
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24) A method as defined in claim 23/ wherein the second 
..instruction data element is associated to a second user, 

said method further comprising:. 

a) processing an identifier associated with the second 
user to .determine if the second user has . payment 
authorization privileges; . 

b) preventing the detection of the granting of payment if 
the second user does not have payment authorization- 
privileges. 

25) A method as defined in claim 24, wherein the first user 
and the second user reside in geographically remote 
locations. 

26) A method as defined in .claim 25, wherein the network is 
a global computer network. 

27) A method as defined in claim 19, wherein said method 
further comprises receiving at said biller entity a data 
element selected from the. set .consisting of a credit card 
number, an authorization to debit a bank account and an 
indication that a check will be mailed. 

28) A computer readable medium comprising a program element 
suitable for execution by a computing apparatus for 
processing an invoice over a network, the invoice being 
issued by a biller entity to a customer entity, said 
computing apparatus comprising: 

a) a memory. unit; 

b) a processor operatively connected to said memory unit, 
said program element, when executing on said processor, 
being operative for: 
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i) receiving a first data element associated to the 
invoice, the first data element indicating that 
payment of the. invoice has been approved;. 

ii) • receiving a second data element associated to the 
invoice, the second data element" indicating that 
payment. of the invoice has been authorized; 

iii) detecting granting of payment of the invoice when 
the first data element and the second data element 
have been received, indicating that the invoice has 
been approved and authorized. 

29) A computer readable . medium as defined in claim 28, 
.wherein said second data element is indicative of either 

one of payment authorization and absence of payment 
authorization by the customer entity. 

30) A computer readable medium as defined in claim 29, 
wherein said first data element is indicative .of either 
one of payment approval and' absence of payment approval by 
the customer entity. 

31) A. computer readable medium as defined in claim 28, said 
program element when executing on said processor being 
operative for processing payment of the invoice when the 
granting of payment of the invoice has been detected. 

32) A computer readable medium as defined in claim 28, 
wherein said memory unit is " for storing an entry 
associated to the customer entity, the entry .including at- 
least one record, the record -having an identifier 
associated to a user of a first type, the user of a first 
type having payment approval privileges, said program' 
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element when executing on said processor being operative 
for : 

a) receiving a first user- identifier associated to a first 
user having issued said first data element; 

b) processing said first user identifier at least on part 
. on the basis of the identifier in the record to 

determine whether the first user has payment approval 
privileges; 

c) preventing the detection. of the granting of payment if 
the first user does not have payment approval 
privileges. 

33) A computer readable medium as defined in claim 32, 
wherein the entry further comprises a second record having 
an identifier associated to a user of a second type, the 
user of a second type having- payment authorization 
privileges, said, program element, when executing on said 
processor, being operative for: 

a) receiving a second user identifier associated to a 
second user having issued said second data element; 

b.) processing said second user identifier at least o.n part 
on the basis of the identifier in the record to 
determine whether the second. user has payment 
authorization- privileges; 

c) preventing the detection of the granting of payment if 
the first user does' not have payment authorization 
privileges. 

34) A computer readable medium as defined in claim 28, said 
program element, when executing on said processor, being 
further operative for receiving a data element selected 
from the set consisting of a credit card number, an 
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authorization to debit a bank account- and an indication 
that a check will be mailed. 

35) An electronic ■ invoice presentment and . payment 
remittance system including a network, a biller computing 
unit with- computer-readable medium, a first customer 
computing unit with computer readable medium, a second 
customer computing unit with computer readable .medium, the 
computer-readable . media having computer-executable 
instructions for performing steps comprising: 

a) operatively linking the biller computing unit and 
customer computing unit to the network; 

b) generating an invoice at the biller computing unit; 

c) making the invoice electronically available to the 
first customer computing unit over the network; 

. d) facilitating' entry of approval instructions at the 
first customer computing unit and following said entry, 
routing the approval instructions to the biller 
computing unit; 

e) making the invoice electronically available to the 
second customer computing unit over the network; 

f ) facilitating entry of authorization instructions at the 
second customer computing unit and following said 
entry, routing the authorization instructions to the 
biller computing unit; 

g) .processing payment of the invoice at the biller entity 
when', the following conditions are satisfied: 

i) the approval instructions from- the. first customer 
computing unit indicate that .the invoice has been 
approved; and 
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ii) the authorization* instructions .from the- second 
customer, computing unit indicate that the invoice has 
been authorized. 

36) A system as defined in claim 35, wherein the computer 
readable media has computer executable instructions for 
facilitating entry at- the second customer computing unit 
of payment instructions, including data selected from the 
set consisting of a. credit card number, an authorization 
to debit a bank account and an indication that a. check 
will be mailed. . ■ 

37) A system as defined in claim 36, wherein the payment . 
instructions include a payment amount. 

38) A system for electronically presenting and granting 
payment of invoices, said system comprising: 

a) means for generating an. invoice at a biller; 

b) means for making the invoice electronically available 
to a customer entity; 

c) means for enabling a first .user associated to the 
customer entity to approve the invoice; 

d) means for enabling a second user associated to the 
customer entity to authorize payment of the invoice, 
the second user being distinct from the first user; 

e) means transmitting from the customer entity back to the 
biller entity a data element indicative that payment of 
the invoice has been approved; 

f ) means for transmitting from the customer entity back to 
the biller entity a data element indicative that 
payment of the invoice has been authorized; 
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g) means for processing payment of the invoice at the 
biller when payment of the invoice has been approved 
and authorized. ■ - 

39. A method for electronically presenting and granting 
payment' of invoices, comprising the following steps: 
a) generating an invoice at a biller; 

•b) making the invoice electronically available to a 
customer entity; 

c) enabling a plurality .of users associated to the 
customer entity to complete respective stages of a 

■ multi-stage invoice handling process; 

d) transmitting from said plurality of users data 
elements indicating that respective stages of the 
a multi-stage invoice handling process have been 
completed; 

.e) . processing payment of the invoice at the biller 
when the data elements, indicative that respective 
invoice processing, stages have been completed, are 
received at the biller and indicate that the 
multi-stage invoice handling process has been 
completed. 
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Abstract of the Disclosure 

A method and system for electronically presenting and 
5 . granting payment of invoices offering multi-stage invoice 
handling capability is provided. An invoice is generated at 
a biller entity and is made electronically available to a 
customer entity. A first user associated to the customer 
entity is enabled to approve the invoice and a second 

10 associated to the customer entity and distinct from the 
first user is enabled to authorize payment of the invoice. A 
data element indicative that payment of the invoice has been 
approved is transmitted from the first user to the biller 
entity. Similarly, a data element indicative that payment 

15 of the invoice has been authorized is transmitted from the 
second user to the biller entity.. Payment of the invoice is 
processed, at the biller entity when payment of the invoice 
has been approved and authorized. 
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Invoice 
Facture 



RE-PRINT/PIEIMPRESSION 

ORIGINAL 

PAGE: 1 



TKD'S DISTINGUISHED AUTO SHOP 
222 ST. CATHERINE 
HO NT REAL QU 
JIB 7X9 



PATRON No. -No CLIENT: 

tNVOtCE/ 
FACTURE . 

MM/DD/YYYY NO. • No - 
10/24/2000 006442734 



12345 A 

' BtU Of LADING NUMBER 
NUMEflO DE CONNAJSS EMENT 

GLABCDE1234567890 



Please refer to this number when making remittance " 
vefllez rappeller ce numero lors de votre payment 



ROUTE* IT1NERAIRE - CN 



EQUIPMENT NUMBER 
N°DU MATERIEL 



WAYBILL -FEUILLEDE ROUTE DESTINATION DARTMOUTH, NS 
MM/DD/YYYY No N° 



ETTX 123456 10/32/2000 987654 

CUSTOMER REFERENCE No. PURCHASE ORDER No 
N 3 REFERENCE CLIENT N°BON DE COMMAND E 



CONSIGNEE* DESTINAT AIRE 

TED'S DISTINGUISHED AUTO SHOP 



ORIGIN «Ofli61NE NEW WESTM1NST, BC 



Prkx Origin 
Origins pr4c. 



SHIPPER * EXPEDITEUR 

TED'S DISTINGUISHED AUTO SHOP 



WEtGTH 'POIDS 



ALLOWANCE NET 
TOLERANCE 



00123456 100800 
STCC 3711120 



LENGTH* LONGUEUR CAPACITY * CAP ACITE KIND* TYPE 

85Sf 5E D C FUR ££ HED OR DEREO FURNISHED ORDERED FURNISHED PAY STATUS 
DEMANOEt LIVREE DEMANDEE UVREE OEMANDtE UVfiEE MODE DE PAIE 



EE 
V411 



MOTOR VEHICLES (AUTO), PASSENGER, SET UP 

DESCRIPTION OF ARTICLE -i 
DESCRIPTION CTARTICLE 



FREIGHT ADVA WE . PREPAID 

f RAIS Dc TRANSPORTFRAIS HOPS REPARTITION PORT PAVE 



AS PER CAR 



HARMONIZED SALES TAX 9 15% 



CONTRACT : CN 12345 - 

VEHICLE IDENTIFICATION NUMBER t 



GLADCDH1234567890 



1,234 
1 



392.55 
58.88 



CARE OF PARTY ABCDEFGH LTD 



PAY THIS AMOUNT (N CAD FUNDS 
MONTANT A PAYER EN DEVISES CAD 



$451.43 5143 

PLEASE OUOTE INVOICE NUMBER ' 

VEILLEZ RAPPELER L£ N°DE FACTURE: 0084 52034 



FIG. 6 



